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Abstract 

We show how an off-path (spoofing-only) attacker can 
perform cross-site scripting (XSS), cross-site request 
forgery (CSRF) and site spoofing/defacement attacks, 
without requiring vulnerabiUties in either web-browser 
or server and circumventing known defenses. Attacker 
can also launch devastating denial of service (DoS) at- 
tacks, even when the connection between the client and 
the server is secured with SSL/TLS. The attacks are prac- 
tical and require a puppet (malicious script in browser 
sandbox) running on a the victim client machine, and at- 
tacker capable of IP-spoofing on the Internet. 

Our attacks use a technique allowing an off-path at- 
tacker to learn the sequence numbers of both client and 
server in a TCP connection. The technique exploits the 
fact that many computers, in particular those running 
Windows, use a global IP-ID counter, which provides a 
side channel allowing efficient exposure of the connec- 
tion sequence numbers. 

We present results of experiments evaluating the learn- 
ing technique and the attacks that exploit it. Finally, we 
present practical defenses that can be deployed at the fire- 
wall level; no changes to existing TCP/IP stacks are re- 
quired. 

1 Introduction 

TCP is the main transport protocol over the Internet, 
ensuring reliable and efficient connections. TCP was 
not designed to be secure against Man-in-the-Middle 
(MitM); in fact, it is trivially vulnerable to MitM attacks. 
However, it seems that man-in-the-middle and eaves- 
dropping attacks are relatively rare in practice, since they 
require the attacker to control routers or links along the 
path between the victims. Instead, most practical attacks 
involve malicious hosts, without MitM capabilities, i.e., 
the attackers are off-path. 

In our attacks, as well as in many other off-path attacks 
(e.g., SYN-flood L42J, DNS-poisoning L22J), the attacker 



sends spoofed packets, i.e., packets with fake (spoofed) 
sender IP address. Due to ingress filtering ll24l[T5l l5l and 
other anti-spoofing measures, IP spoofing is less com- 
monly available than before, but still feasible, see ll2l [T4l . 
Apparently, there is still a significant number of ISPs that 
do not perform ingress filtering for their clients (espe- 
cially to multihomed customers). Furthermore, with the 
growing concern of cyberwarfare and cybercrime, some 
ISPs may intentionally support spoofing. Hence, it is still 
reasonable to assume spoofing ability. 

However, there is a widespread belief that an 'off- 
path' spoofing attacker, cannot inject traffic into a TCP 
connection. The reasoning is that an incoming TCP 
packet must contain valid sequence number (or be dis- 
carded); the sequence number field is 32 bits long and 
initialized using randomness, therefore, it seems unlikely 
that an attacker can efficiently generate a spoofed packet 
which will be accepted by the recipient, i.e., inject data 
into the TCP stream. 

This belief is also stated in RFCs and standards, e.g., 
in RFC 4953, discussing on TCP spoofing attacks (see 
ll42l . Section 2.2). Indeed, since its early days, most In- 
ternet traffic uses TCP - and is not cryptographically pro- 
tected, in spite of warnings, e.g., by Morris [33 1, Bellovin 

Elllol). 

Of course, TCP injections are easy, for implementa- 
tions using predictable initial sequence numbers (ISNs). 
This was observed already by Morris at 1985 ll33l and 
abused by Mitnick (Wl. Later, at 2001, Zalewski 
found that most implementations still used predictable 
sequence numbers ll46l . 

However, by now, most or all major implementations 
ensure sufficiently-unpredictable initial sequence num- 
bers, e.g., following |[T9l|20l. Does this imply that TCP 
injections are infeasible? 

Zalewski |48 | suggested that it may be possible to 
spoof a non-first fragment of a (fragmented) TCP packet, 
when the values of the fragment IP-IDs are predictable. 
In particular, existing implementations of Windows use 
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globally-incrementing IP-ID values, which are easy to 
predict. Zalewski's attack may also be applicable to 
Linux, using the IP-ID prediction techniques in ifTTl . 
However, exploiting such non-first-fragment TCP in- 
jections seems challenging; furthermore, currently al- 
most all TCP implementations use path MTU discovery 
II32II3TI and avoid fragmentation completely. Hence, Za- 
lewski's attack (on TCP) will rarely work in practice. 

Yet, we show that TCP injections are still possible. 
We present an efficient, practical technique, based on 
globally-incrementing IP-ID, allowing an off -path adver- 
sary, Mallory, to inject data into a TCP connection be- 
tween two communicating peers: a client C and a server 
S. The attack is not immediate, and requires a connection 
lasting a few dozens of seconds. We present experimen- 
tal results, showing that our techniques allow efficient, 
practical TCP injections. Furthermore, we show, that the 
attacks have significant potential for abuse. Specifically, 
we show how our TCP injection techniques, allow both 
circumvention of the Same Origin Policy ||6l l49ll and dev- 
astating DoS attacks. Details follow. 

Our TCP injection technique is related to a proposal 
for TCP injection, by klm fTl\. The technique described 
by klm had some limitations, e.g., it did not work for 
clients connected by a firewall. More significantly, klm 
did not present experimental results; our experiments 
show that their technique, even with some improvements, 
results in low injection success rates, unless the attacker 
has low latency to the victim (as when they are on the 
same LAN). Our techniques avoid this limitation. We 
provide a detailed comparison between our technique to 
ipTl in appendix |A| 

Like 1481 [TtI l27l . our technique is based on the pre- 
dictability of the IP-ID (e.g., in Windows); however, in- 
stead of using the predictable IP-ID to intercept or mod- 
ify fragmented packets, as in [48 , 17 1, we use the changes 
in the IP-ID as a side channel. We use this side-channel 
to allow the attacker to detect difference in responses for 
crafted probe packets that she sends to the client; our im- 
plementation uses specific probes, but others may exist. 

Previous works noted that the predictable IP-ID can 
be used as a side channel, allowing an attacker to use one 
connection to learn about events in another connection, 
which is undesirable. Gont fTSl mentions several ways 
in which the side channel based on globally-incremented 
IP-ID can be abused. However, their impact is modest. 
In particular, the side-channel can be used to perform the 
idle (stealth) scan attack IjTl Eg] |29J, and to count the 
number of machines behind NAT ||9l . 

However, vendors continued using globally- 
incrementing IP-ID values, even after we presented 
our initial TCP injection results to them, and being 
aware of the previous attacks exploiting the globally 
incrementing IP-IDs. Their justification is that they be- 
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Figure 1: Network Model. Centerswww.mallory.com, 
the adversarial web page. A script on that page forms a 
connection with www. s. com. 



lieved that such attacks are impractical and too complex 
to be exploited in practice. They confirmed our results 
and agreed that they are feasible; they will address the 
problem in new releases. 

We believe that this response is 'too little, too late', 
and that it is critical for the community to be aware of the 
threat and apply mitigations (Section|7|i. A more contro- 
versial conclusion is the need to apply more prudent ap- 
proach to network security vulnerabilities, and respond 
to early indications of weakness, without waiting for a 
complete exploit; see discussion in Section [8] 

Much of our work focused on analyzing what are the 
practical implications of the TCP injection. We study 
two approaches to exploit TCP injections: to circumvent 
address based server authentication, usually referred to 
as Same Origin Policy (SOP) ||6l l49]| ; and to launch a De- 
nial of Service (DoS) attack. We discuss each of these 
briefly in separate subsections below, and in depth in 
Sections 12] and |3] All attacks are based on the same at- 
tacker and network assumptions which we now describe. 

Attacker Capabilities and Network Model 

All our attacks work in the same settings: an off-path, 
IP-spoofing attacker We also assume that the attacker is 
able to control some puppets [4J, i.e., scripts, applets or 
other restricted (sandboxed) programs, running on cUent 
machines accessing an adversarial web site. This is il- 
lustrated in Figure [T] where C enters a site controlled by 
the adversary, Mallory. This allows Mallory to run a ma- 
licious script within C's browser sandbox. The script al- 
lows Mallory to (1) form the connection between C and 
S, and (2) probe C's connection with S and avoid firewall 
filtering. The first allows Mallory to choose the victim 
server (S), we show how the second allows exposure of 
the TCP connection's four tuple. 

As mentioned above, our attacks require that the con- 
nection from C and S will not be short; since Mallory 
forms this connection (using the puppet), she can ensure 
that it does not terminate by sending periodic requests 
to the server. In persistent HTTP connections, all re- 
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quests are over the same (victim) connection and ensure 
it does not close. Persistent HTTP connections are the 
defauh configuration of apache servers and are also em- 
ployed by many large web-servers (e.g., Facebook, Ya- 
hoo!, Google), but not all (e.g., live.com, the Japanese 
version of Yahoo!). Our attacks are browser independent, 
as we illustrate in experiments in the following sections. 

1.1 Breaking SOP and Address-Based Au- 
thentication 

TCP injection attacks were key to some of the most 
well known exploits, specifically, attacks against address 
based client authentication, e.g., see [38, 10|. How- 
ever, as a result, address-based client authentication has 
become essentially obsolete, and mostly replaced with 
secure alternatives such as SSH and SSL/TLS. We be- 
lieve that the only widely-deployed use of address based 
chent authentication, is to identify clients involved in 
DoS attacks such as SYN flooding; and this threat can 
be dealt with by simple client-response authentication, 
possibly using cookies to avoid state-exhaustion on the 
server |fT3l. 

However, current web security still relies, to large ex- 
tent, on the Same Origin Policy |l6l|43, i.e., on address 
based server authentication; our results show that rely- 
ing on addresses to authenticate the servers is also risky. 

Using TCP injections to attack address based server 
authentication, e.g., to perform XSS attacks, is more 
challenging than using it to attack address based client 
authentication. In attacks on address based client au- 
thentication, the off-path attacker sends the initial SYN 
to open a new connection; hence, she knows the client's 
sequence number, as well as the source and destination 
IP addresses and ports; she 'only' needs to predict the 
server's sequence number. In contrast, to attack address 
based server authentication, the off-path attacker must 
guess both sequence numbers, as well as the IP addresses 
and ports of both parties; guessing the client port could 
also be challenging, as the chent may choose it arbitrar- 
ily. 

To circumvent the same origin policy |l6l|49l, the off- 
path attacker sends forged responses for requests that C 
sends to another server S. This attack is facilitated in two 
phases: first the puppet opens a connection to the victim 
server, allowing TCP injection into this connection; then 
the puppet requests an object, allowing the attacker to 
send the script in a (spoofed) response. 

In particular, this allows powerful cross site scripting 
(XSS). XSS is one of the most critical attacks on web 
security, however, current XSS techniques depend on 
implementation vulnerabilities, usually of the site (e.g., 
fl31 \49)). and sometimes of the browser f25l. In con- 
trast to typical XSS attacks, our attack does not rely on 



a server side or browser vulnerability. Moreover, since 
Mallory can choose the server S, any persistent HTTP 
connection between C and a server is vulnerable (see 
above). Connections with HTTPS servers are not vul- 
nerable to XSS since Mallory cannot inject content into 
the cryptographically sealed session. 

Furthermore, the XSS ability allows injection of re- 
quests, i.e., cross-site request forgery (CSRF) (4T\. This 
circumvents existing defenses, such as the use of cook- 
ies, referrer header and hidden field, since all of these are 
available to the (injected) script (see |34|). The CSRF 
attack can be prevented by challenge response methods 
that require user involvement, such as password authen- 
tication or CAPTCHAs. 

The XSS ability also allows advanced phishing at- 
tacks. In particular, this provides efficient means for de- 
tection of browsing history, more effectively than previ- 
ous techniques, e.g., ||28ll44ll . 



1.2 Devastating DoS attacks 

An off -path attacker can use the knowledge of TCP pa- 
rameters (IPs, ports and sequence numbers) in several 
ways, to attack the availability of a communication ser- 
vice. 

In 2004, Watson observed that BGP connections used 
a constant client port, and typically have very large win- 
dows; this makes it feasible for an off-path adversary 
to reset BGP connections B3l (despite random initial 
sequence numbers). However, appropriate countermea- 
sures make this attack inapplicable today 1 13|. 

We show how a spoofing, off-path attacker, who con- 
trols a limited number of (weak) puppets, can deploy 
formidable DoS attacks, which so far were known to re- 
quire stronger attacker capabilities: the Ack-Storm attack 
111 and the Optimistic-Ack attack |[37l. Both are DDoS 
attacks, which use TCP control plane to generate excess 
amount of traffic. The Ack-Storm attack [I], is usually 
performed by MitM adversaries, possibly with limited 
eavesdropping abilities. The Optimistic-Ack attack ||37| 
typically requires client cooperation (zombie) and per- 
suades the server to send data in a high capacity, more 
than that allowed by C's link. Since in both these at- 
tacks, Mallory injects data only to the TCP layer (and 
not to the application), these attacks also work when the 
victim servers use SSL. 

Launching these attacks simultaneously on multiple 
client-server pairs may allow Mallory to conduct an im- 
proved variant of the Coremelt attack f40| and congest a 
core hnk of the Internet, using only puppets. 
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1.3 Organization 

The next two sections focus on the apphcation of the 
TCP injection technique. In Section 2 we present our 
off-path attacks on the confidentiality and integrity (au- 
thentication) of the communication between cHent and 
server, including the XSS, CSRF and phishing attacks. 
In Section 3, we present our off-path DDoS attacks. 

Sections 4-6 present the TCP injection technique it- 
self Section 4 presents the first step, which is expos- 
ing the server's sequence number Section 5 continues 
the attack, to expose the client's sequence number as 
well. Section 6 discusses deployment challenges, im- 
provements to meet these challenges, and experimental 
results. 

Finally, Section 7 proposes defenses against the at- 
tacks, and Section 8 presents a concluding discussion. 



2 Off-Path Data Integrity Attacks 

In this and the following section we present and em- 
pirically evaluate exploits of TCP injections. We focus 
on long-lived-connection injection attacks, where an off- 
path attacker learns the sequence numbers of an existing, 
long-lived TCP connection, between a given TCP client 
and server (identified by their IP addresses and ports). 
Motivated by these exploits, in Sections |4]|6] we present 
and evaluate the technique we employ to study the se- 
quence numbers. 

Specifically, we show critical exploits of long-lived 
connection injections. In this section we focus on two 
exploits: the first allows an off-path attacker to run a ma- 
licious script in the context of an arbitrary website of the 
attacker's choice, without depending on a vulnerability 
of the server (e.g., bug in input sanitization) or of the 
browser; this is a new, devastating type of XSS attack 
||43] |251 . The second exploit allows the same attacker 
to present spoofed web-pages for clients. In the follow- 
ing section we show how off -path attackers can use long- 
hved connection injections to cause devastating DoS at- 
tacks. All exploits work in the same setting, illustrated 
in Figure [T| 

2.1 Identifying the Victim Connection 

To launch the long-lived-connection injection attacks, 
the attacker must identify a connection between the client 
and server which is defined by the IP addresses and ports 
of the participating peers. 

The exploits use the puppet running on the client to 
open such (long-lived) connections. The server's IP and 
port are, of course, known. To find the client's IP and 
port, the puppet opens another TCP connection to the 



attacker and over it, sends packets to the attacker's ma- 
chine. These packets contain the client's IP address. 

The final challenge is to detect the client port. Many 
clients, in particular, those running one of the Windows 
family operating systems, assign ports to connections in- 
crementally. We use the puppet to open a connection to 
the attacker's remote site before and after opening the 
connection to the victim server, incremental port assign- 
ment allows the attacker to learn the client's port; see 



step A in the attack process described in Section 2.2.1 
below. Client port exposing may fail if the puppet com- 
municates with the server or attacker via a NAT device 
that randomizes the client port (since 'external' ports are 
not incremental). In an ongoing research we investigate 
this problem and provide, details of a different technique 
that allows an off -path attacker to detect the client port in 
a connection. 

It remains to describe, in the following subsections, 
the unique aspects to each of the exploits and evaluate 
their impact. 

2.2 Off-Path Injection XSS (or: XSS of the 
Fourth Kind) 

In a Cross-site scripting (XSS) attack, the attacker causes 
the browser to run malicious, attacker-provided script (or 
other sandboxed code), with the permissions of scripts 
within a victim server web-page. 

In |'25l, Klein identifies three kinds of XSS attacks. In 
persistent/stored XSS attack, the script is received from 
the victim server, as part of the contents of a page stored 
by the victim server In reflection XSS attack, the script 
is 'reflected' by the victim server to the client, after the 
server receives the script from the browser (typically vis- 
iting a malicious website). Finally, in a DOM-based XSS 
attack, the script is received by the browser directly from 
the attacking server; a browser vulnerability (bug) causes 
the browser to consider the script as coming from some 
other victim server. 

Both reflection and persistent/stored XSS attacks, ex- 
ploit 'bugs' in the web application. Well designed sites, 
using appropriate defenses such as Web Application 
Firewalls (WAF), should eliminate these attacks; see, 
e.g., |45 |. DOM-based XSS attacks do not require any 
bug in the site, but depend on bugs in the browser; the 
relevant known bugs were quickly patched by browser 
vendors. 

Long-lived-connection injection attacks, allow a new, 
fourth kind of XSS attacks: off-path injection XSS at- 
tacks. In these attacks, the malicious script is sent by the 
attacker to the browser, with (spoofed) source IP address 
of the victim server. If the script it injected correctly, 
with correct TCP/IP parameters and within correct HTTP 
context, then the browser executes it in the context of the 
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victim site. 

2.2.1 Attack Process 

We next explain the technique we employ to use long- 
lived injection attacks to perform off-path XSS injec- 
tions. Like our other exploits, we assume that the user 
visits a website controlled by the attacker from where 
he receives and executes a puppet (malicious script) yj. 
The attack has five steps and proceeds as follows: 

A. Form Connection, Expose Client Port 

Puppet opens a new connection to a server controlled by 
the attacker, then a connection to the victim web server 
and finally another new connection to a server controlled 
by the attacker. Let the client port numbers that the at- 
tacker observes for the first and third connections be pi, 
pi,. We use the counter property of Windows port as- 
signment: if p3 = pi +2, then we assume that the client 
used port pi + \ for the (middle) connection to the victim 
server. Otherwise, repeat. 

B. Expose Connection Sequence Numbers 

Puppet maintains the connection with the victim server 
alive by sending periodic requests for small objects. Dur- 
ing this time, attacker runs the sequence exposure attack 
described in Sections [4] [5] If sequence exposing fails, 
restart entire attack. 

C. Send 'Dummy' Request 

Puppet sends the victim server a request for some web 
page (over the same persistent connection), e.g., using 
an iframe, and informs the attacker on that request. Note 
that the puppet runs in the context of the attacker site; 
hence, the attacker and puppet can communicate and co- 
ordinate the attack without restrictions. 

D. Send Spoofed Response 

Attacker sends spoofed response to the client, containing 
exact expected TCP parameters, and a web page contain- 
ing the malicious script. 

E. Script Execution 

Browser receives the spoofed response as if it was sent 
by victim server, hence, executes script with permissions 
of the victim server. Figure |2] shows a successful run of 
this attack on the Mozilla Firefox browser. 

2.2.2 CSRF Exploit 

As indicated in ||45l 1411 . once attackers succeed in an 
XSS attack, i.e., run a malicious script in the browser, in 
the context of a victim site, they can exploit it in many 
ways. In particular, such XSS attack allows attackers to 
send a forged (fake) request to the server on the user's 
behalf, i.e., a cross site request forgery (CSRF) attack. 
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Figure 2: An XSS Attack. Mallory runs a script in 
context of www.victim-server.com within Mozilla Fire- 
fox sandbox. The address bar indicates the user is at 
www.mallory.com, but the message box context indica- 
tion shows that the script (that Mallory provided) runs 
from www.victim-server.com. 

circumventing all known defenses against CSRF attacks 
for non-secured connections, except for (few) defenses 
requiring extra user efforts for submission of each (sen- 
sitive) request; see |34|. 

Note that since the attackers (cross site) scrips can read 
the entire response that the user receives from the vic- 
tim web-server, they would even be able to circumvent 
advanced proposed defenses, which require new browser 
mechanisms. In particular, they can foil the origin header 
proposed by Barth et al. against CSRF attacks |7|, as 
well as policy-based defense mechanisms against XSS, 
e.g.. Content Security Policy (CSP) 11211 |39l . 

2.3 Experimental validation 

In this subsection we evaluate the applicability of the 
XSS attack on web-users. The client machine in the fol- 
lowing experiments is protected by Windows Firewall. 

The success of the XSS attack depends on success- 
fully exposing of the sequence numbers used in the con- 
nection the client has with the victim server. The success 
rate of the exposure technique that we employ (presented 
in Sections |4] |5]) depends on the rate of packets that the 
client machine sends. In Section |6] we present another 
set of experiments that specifically evaluates the injec- 
tion technique for different environments. In the mea- 
surements below, C sends 32 packets per second on av- 
erage. 

We tested whether connections with each of the top 
1024 sites in Alexa ranking |[3] are vulnerable to off- 
path XSS attacks: our client machine connects to the at- 
tacker (www.mallory.com), who then tries to run a script 
in context of one of the top sites. The script provides 
an indication of a successful injection by requesting an 
image from www.mallory.com. Note that our attacker 
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Figure 3: Rate of successful XSS attacks on connections 
to popular sites. 
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Figure 4: The applicability of the injection attacks on 
various sites. 



only communicates with the client, and does not have 
any interaction with the victim servers. In Figure [3] we 
compare the results for three common browsers and ob- 
serve that the attack is not browser-dependent. The im- 
mune connections are generally of the following types: 
(1) secured with SSL (HTTPS), this prevents the attacker 
from injecting his script to the connection (step D in the 
attack); (2) sites that do not use the HTTP keep alive 
option, this prevents the attacker from keeping the long 
connection with the server that is required to expose the 
sequence numbers (step B in the attack). In Figure |4] 
we provide distribution of the top 1024 sites in Alexa 
ranking; showing that 80% percent of them appear vul- 
nerable (line 3 in Figure]?]). A comparison of this result 
to those presented in Figure ]3] shows that the XSS at- 
tack was, in fact, successful on roughly 75% of the sites 
that appear vulnerable. Among the vulnerable sites on 
which we ran a successful attack are www.facebook.com, 
www.yahoo.com and www.amazon.com. 

2.4 Web Spoofing/Phishing/Defacement 

In addition to the XSS exploits, attackers can use TCP in- 
jections to perform web spoofing (which is key to phish- 
ing attacks). Namely, the attacker waits for the user to 
browse to some victim server, e.g., http://www.bank.com, 
and injects his data to the connection. In this attack, the 
attacker provides a spoofed version of the web-page to 



the client. This spoofing exploit can expose sensitive 
user-provided information such as passwords and may 
trick the user to download malware. An implicit as- 
sumption of this attack is that the initial web-page that 
the user receives, and which the attacker forges, i.e., 
http://www.bank.com, is not protected by SSL. This is 
the situation in most sites, which do not use SSL/TLS at 
all. 

The attack also works for many sites which do use 
SSL/TLS, but only via a link, e.g, to the login page 
https://www.bank.coni/login.php. This approach is com- 
mon since it reduces the load on the server by delay- 
ing setup of SSL connections until these are required 
(in the banking example, for login); see line 4 of Figure 



Web-spoofing can allow the attacker to circumvent 
the use of encrypted connections (SSL/TLS), using tech- 
niques/tools such as SSL-strip |30|, i.e., replace links on 
the original page to phony pages (on the attacker's site). 

To succeed in a web-spoofing attack, the attacker 
would best send the spoofed page as a response to a re- 
quest made by the user (since then the page appears au- 
thentic to the user); hence, the attacker should be able 
to detect the request for the page and send a response. 
We solve this problem by having the puppet open a con- 
nection to the victim server in advance providing suffi- 
cient time to expose the sequence numbers used in the 
connection. We leave the connection open (by sending 
'dummy' requests periodically); and probe for user activ- 
ity by identifying a change in the client's sequence num- 
ber. In order to detect this change that indicates that the 
client had sent a request to the server, the attacker peri- 
odically conducts a client-seq-test; this test is a building 
block of the sequence numbers exposing technique and 
we provide its details in Section]5] Briefly, the test allows 
the attacker to test whether the client sequence number is 
above some value; testing using the exposed (i.e., last 
known) value of client sequence number allows to detect 
such change. Once we detect such activity over the con- 
nection, we assume that the user had sent a request to the 
server for the home page and send a spoofed (modified) 
page. 

This web spoofing technique assumes that the user 
opens the page for the victim-server while the puppet is 
still running, e.g., in a different tab of the same browser 
or in a zero-size iframe. Furthermore, it assumes that the 
browser employs connection sharing between different 
tabs, i.e., one TCP connection is used to communicate 
with the same server via several tabs of the browser. TCP 
connection sharing is employed by the current versions 
of Internet Explorer, Firefox and Chrome (and possibly 
other browsers). 



'Line 4 of Figure]4]count.s sites which have persistent connections, 
to both http and https. Note that some of these sites may not often 
use https, while others may use https but in a different domain. 
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Figure 5: Web Spoofing/Defacement Attack. Ma I lory 
waits for the user to enter J.P. Morgan bank website, 
when he enters he injects a phony page. In this figure 
Mallory added a devil image. 



Another assumption is that the user receives the at- 
tacker's response before the server's; this appears as a 
race that would be difficult to win for an attacker far 
from the client machine. However, the attacker can avoid 
this race by injecting data to the client (as the server) in 
advance: the injected data artificially increments the se- 
quence number that the client expects from the server 
while the true server would still use the 'normal' se- 
quence number, causing the client to reject all data sent 
by the server. 

2.4.1 Example: Spoofing J.P. Morgan 

The J.P. Morgan bank website is an example of a sen- 
sitive site that is vulnerable to this spoofing/phishing at- 
tack; it uses HTTP keep alive option and its homepage 
is not protected by SSL. Hence, this website is vulner- 
able to the web spoofing attack above. Figure |5] shows 
the result of a successful web spoofing attempt: here the 
client has two tabs open in his browser. The current tab 
(in focus) shows the J.P. Morgan homepage that Mallory 
provided; the devil image (that does not exist in the orig- 
inal page) indicates that this page is spoofed. J.P. Mor- 
gan homepage contains a client log-on link that in the 
original site switches to SSL. In the spoofed version, the 
link is to a web-page in Mallory's site. In the other tab, 
the victim is in www.mallory.com; this allows Mallory to 
monitor the requests that the user (may) send J.P. Morgan 
and identify the correct time to inject the spoofed page. 

3 Off-Path Denial-of-Service by Puppets 

We next describe possible exploits of long-lived- 
connection injection attacks to disrupt network commu- 
nication. Namely, we show how attackers can build on 
these attacks, to launch devastating Distributed Denial- 
of-Service (DDoS) attacks. As before, we consider an 



off-path IP-spoofing attacker, who also controls a sig- 
nificant number of 'puppets', i.e., scripts running in 
browsers of unsuspecting users. As argued in [4|, it is 
relatively easy for attackers to control a large number of 
puppets in this way. 

However, puppets have limited ability to launch 
DDoS attacks. One reason are limitations placed by 
the browsers on the number of concurrent connections 
opened by the same web-page. Another reason is that, 
due to their execution within a sandbox, puppets can only 
use standard TCP connections. In particular, if the at- 
tack succeeds in causing congestion and loss, then TCP 
connections, including those of the puppets, will signif- 
icantly reduce their window size (and hence their traffic 
rates). Therefore, while puppets can be used for DDoS 
attacks, their impact is much less than that of 'regular' 
malware (zombies/bots). 

In contrast to the data integrity attacks in the previ- 
ous section, the attacks below use TCP control plane to 
cause congestion. Since there is no attempt to inject data 
to the application layer, even SSL/TLS protected sites are 
vulnerable. Hence, these attacks are applicable to web- 
sites that support persistent HTTP connections, with or 
without SSL/TLS, e.g., to about 80% of the 1000 most 
popular sites (see line 2 in Figure]?]). 

3.1 Off-Path Optimistic Ack Attack 

We first describe Off-path Optimistic Ack; this is a vari- 
ant of the Optimistic Ack DoS attack 1.371 . These at- 
tacks cheat TCP's congestion control mechanism, caus- 
ing senders to believe that most of the data they sent was 
already received, and hence that they can send more data 
(congestion window is not full), and also to increase the 
size of the congestion window. This can result in huge 
amplification factors, see [37], unless servers use per- 
connection bandwidth quotas or use other defenses. 

In both Optimistic Ack attacks (ours and the original 
ll37l ). the attacker sends to the server acknowledgment 
packets (Acks), as if the client received all packets sent 
by the server (although packets are still in transit or even 
lost). As a result, the server continues sending informa- 
tion, with increasing window sizes (and hence rates). 

In the original attack |37|, the client must run mal- 
ware, with ability to send 'raw IP' packets (i.e., not ac- 
cording to the TCP specifications). This is a significant 
requirement; recent operating systems make it harder for 
malware to obtain such ability. Furthermore, the original 
attack may be blocked by a firewall on the client side, 
by detecting the unusual high rate. Note that since by 
requiring only puppets, attacker is more likely to control 
enough clients to succeed in the attack, in spite of coun- 
termeasures such as per-connection quotas. 

Our long-lived-connection injection attack, allows an 
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off -path attacker to perform an off -path variant of the Op- 
timistic Ack attack, as follows. The attacker only needs 
a puppet on the client machine to open the TCP con- 
nection with the victim server and learn the client port 
and sequence numbers. Following this, the puppet re- 
quests some large object from the server and is no longer 
needed; the attacker sends Ack packets as done by the 
client in the original attack, and - if not using SSL/TLS - 
the attacker can even send new request(s) if needed. Note 
that even if the client's firewall (detects the attack or for 
some other reason) begins blocking packets on this con- 
nection from both directions, this does not help since we 
provide the Acks to the server from the off -path attacker. 
Furthermore, RFC-compliant RST packets that the fire- 
wall (or client) may send, would be out of the server's 
window and hence ignored, and would not tear the con- 
nection. Server-induced verifications, by intentionally 
dropping or reordering packets periodically, as suggested 
in ll37l . seem one of the best (or only) defenses. 



3.2 Off-Path Ack-Storm DoS Attack 

In the original Ack-Storm DoS attack the attacker 
needs to have some (limited) ability to eavesdrop on 
packets. From these packets, the attacker learns the TCP 
parameters (IP addresses, ports, and sequence numbers). 
Using these, the attacker sends two spoofed data packets, 
one to each of the two ends of the connection. According 
to the TCP specification, and in most TCP implementa- 
tions, upon receiving an Ack for data that was not yet 
sent, TCP sends back a 'duplicate Ack' - i.e., resends the 
previously sent Ack. As a result of receiving the pair of 
spoofed data packets, one at each peer, both peers begin 
sending acknowledgment packets to each other. Since 
these Acks acknowledge data which was actually sent by 
the attacker, not by the peer, then each of these Acks will 
only result in another duplicate Ack returned, and this 
process will continue indefinitely. 

The attacker can send additional data packets to the 
peers, causing additional ping-pong exchanges, quickly 
filling-up the channel capacity. This causes increased 
load on the networks; the fact that the packets involved 
in the attack are very short (just Acks), makes the load on 
routers and switches even higher Eventually, this causes 
packet losses, and legitimate TCP connections sharing 
the same links significantly reduce their rate. 

The off-path Ack-Storm DoS Attack works exactly 
like the regular Ack-Storm DoS Attack, except for us- 
ing the long-lived connection injection technique to al- 
low the off -path attacker to learn the TCP parameters. 
Hence the attacker can run this attack, without requiring 
the ability to eavesdrop. 



3.3 Off-path Coremelt Attack 

Since the two DoS attacks described above can be 
launched using only puppets, it follows that even rela- 
tively weak attackers may be able to cause large amounts 
of traffic from many clients spread around the network. 
This can cause high load on servers, routers and links. 

In particular, by choosing well the pairs of clients and 
servers between which the attacks are launched, the at- 
tackers can cause huge amounts of traffic to flow over 
specific 'victim' backbone routers and links. These back- 
bone networks, connecting large core ISPs (autonomous 
systems), have very high capacities; by sending enough 
traffic to a particular destination, attacker can cause 
queuing and losses in the connecting router As a result, 
Internet connectivity may break - first for TCP connec- 
tions and then even for UDP applications. We use the 
term Off-path Coremelt Attack for the resulting attack on 
core Internet connectivity, since it is an off-path variant 
of the Coremelt attack [40J. The Coremelt attack uses 
a large botnet, sending large amounts of traffic between 
pairs of the bots, with the pairs chosen intentionally so 
that huge amounts of traffic will flow over specific vic- 
tim link/router As shown by simulations in |40|, this 
can result in congesting the victim link/router, and even 
in breaking connectivity in the Network. 

In the Off-path Coremelt attack, the attacker will also 
congest a core link; however, instead of depending on 
pairs of zombies (bots), here the attack just requires a 
puppet at one end. The other end of the connection is 
a legitimate server, and to cause huge amounts of traf- 
fic, the attacker uses one of the two off-path DoS attacks 
described above. 

This attack has three advantages compared to the orig- 
inal Coremelt attack: (1) controlling a sufficiently large 
and correctly-dispersed set of puppets is easier than con- 
trolling a comparable set of zombies; (2) we only need to 
control one end of each connection (the puppet), not both 
ends; and (3) since we use adversary-chosen servers, 
these can have very high bandwidth, higher than avail- 
able to most bots. 

3.4 Experimental Evaluation 

We used the topology illustrated in Figure |6] to test the 
off-path denial of service attacks we presented. In our 
tests we assume that Ma I lory runs a puppet on C and can 
inject data to the TCP connection between C and S (a 
connection that Mallory caused C to establish). 

We evaluate the attacks by measuring the degradation 
of service that they cause to other legitimate connections. 
We consider different round-trip times (RTTs) for the le- 
gitimate connections we measure: the longer the RTT is, 
the greater the congestion windows are. Since every loss 
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halves the congestion window, a more significant effect 
is observed when RTT is high. Furthermore, a higher 
RTT implies that it will take more time for the sender 
to detect a packet loss and retransmit. The base line to 
which we compare the effect of these attacks is line 1 in 
Figure [T] which illustrates the time it takes C* to receive 
a 50MB file from S* under normal conditions. 



(runs puppei 




Mallory 



Figure 6: Network environment for testing the DoS at- 
tacks. Each link specifies its capacity in mbps. 

3.4.1 Off-Path Optimistic Ack Evaluation 

In this attack we aimed to clog the S's link: Mallory uses 
C to request some large file from S and then performs 
the Optimistic Ack attack, persuading S to send data to 
C at high a rate. We evaluated the effect of this attack by 
measuring the degradation of service in a connection that 
S has with some other client C* who tries to download 
a 50MB file. Lines 1 and 2 in Figure [7] illustrate our 
results. Notice the significant difference in attacker and 
server link capacities; the amplification ratio measured 
in this attack is 78 (for every byte that Mallory sends, S 
sends approximately 78 bytes). Furthermore, the attack 
also clogs C's link, as shown by line 4. 

3.4.2 Off-Path Ack-Storm Evaluation 

We use the Ack-Storm attack to congest C's link and 
measure the effect on a different connection that he has 
with some other server S*. In order to congest the link, 
Mallory creates a new Ack 'ping-pong' every 100 ms; 
to create each ping-pong Mallory sends only two short 
(40B) packets. In the connection with S*, C tries to 
download a 50MB file (similar to the previous experi- 
ment). Lines 1 and 3 compare the file transfer time at 
a normal time, to that when the Ack-Storm attack takes 
place. This attack requires much less effort and lower 
bandwidth than the Opt- Ack attack, i.e., has much higher 
amplification ratio; but is limited by the client bandwidth 
(which is typically lower than the server's) this limita- 
tion is illustrated by line 5 which is very similar to line 1 
(normal conditions). 

4 Server Sequence Number Exposure 

In this and the following section we describe the se- 
quence exposure attack where a off-path adversary, 
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Figure 7: Evaluation of Ack-Strom and Opt- Ack DoS 
attacks. The legend indicates for each line the type of 
attack and the peers in the legitimate connection (that 
Mallory aims to degrade). Measurements are the aver- 
age of 50 runs, error-bars mark the standard deviations. 



Mallory, learns the current sequence numbers of a TCP 
connection between C and S. 

We present a two phase attack: first, in this section we 
describe how Mallory learns the server's sequence num- 
ber, sn, which S will use in the next packet sent to C. 
In the second phase, presented in the following section, 
we show how given S's sequence number (sn), Mallory 
efficiently obtains the acknowledgment number that C 
expects; this acknowledgment number is the sequence 
number that C will next use in packets sent to S. In both 
phases Mallory communicates only with C and aids a side 
channel feedback that she receives from C. 

The attacks that we describe in both sections assumes 
that Mallory had previously identified C and S's IP ad- 
dresses and ports; see details on how Mallory exposes 
these parameters in Section[2T| 



4.1 The Server-Sequence Test 

This subsection presents the server-sequence test that al- 
lows Mallory to test whether some sequence number, sn, 
is within the flow control window (wnd) that C keeps for 
packets he receives from S. The key observation is that 
when a connection is in the established state, the recipi- 
ent's handling of an empty acknowledgment packet (i.e., 
acknowledgment with no additional data) differs in case 
that it is not within wnd. The difference depends on the 
32-bit sequence number and allows Mallory to search for 
a valid sequence number The following paragraphs ex- 
plain how: 

Packets that specify an invalid sequence number (i.e., 
outside the recipient's wnd) cause the recipient to send 
a duplicate Ack (for the last valid packet the recipient 
received). However, if the sequence number is within 
wnd, then the receiver does not send any response; the 
reason is that replying with an Ack in this case would 
start a never-ending series of acknowledgments. 

The server-sequence test, illustrated in Figure [Sj has 
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three steps: in the first and third steps Ma I lory sends a 
query to C; this is some packet that causes C to send a 
response packet back to Mallory who then saves the IP- 
ID value in the response. In Section 6. 1 we show how 



Mallory can use the legitimate TCP connection she has 
with C to implement queries and responses (since C is in 
www.mallory.com). In the second step, Mallory sends C 
a probe: this packet is spoofed and appears to belong to 
C's connection with S. The probe in this test is an empty 
Ack packet that leverages the observation above. 

When Mallory receives the responses (for steps 1,3); 
she uses the IP-IDs they specify, / and j, to learn x = j — i, 
the number of packets that C had sent between the two 
queries. Since the Windows IP-ID implementation is a 
single counter for all destinations (incremented on every 
packet that C sends), Mallory learns that sn is within C's 
wnd if X = 1, i.e., C did not send any packet between the 
two queries (see Figure [8]). 



M allory^ 
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Figure 8: Server-Sequence Test. The dashed arrow 
marks the duplicate Ack that C sends S only in case that 
sn is not within the flow control window. If sn is within 
C's wnd, then C does not send that packet and j — i = 1. 

4.2 Learning Process 

The probability that a sequence number that Mallory tests 
is within C's wnd is "'"^-^'^'^ (since wnd is 32 bits long); 
this resembles to the TCP RST forgery attack |43 1 where 
the attacker sends reset packets with arbitrary sequence 
numbers. The value of wnd-size is therefore important; 
Gont also points out the significance of the flow control 
window size in his security assessment for TCP [20J . 

Mallory conducts the server-sequence test until he 
identifies a sequence number within C's wnd. Each test 
is for a different sequence number which is of distance 
^wnd from the previously tested one, where e„,„(/ is an 
estimation of C's wnd-size. Namely, Mallory tests se- 
quence numbers 0,en.„ii,2e„,„ii, etc. Generally, if e^-nd < 
wnd-size, then Mallory would test redundant sequence 
numbers, and if e„,„ii > wnd-size, then Mallory may not 
find a valid sequence number. In our attacks (presented 
in Sections [2] [3]l we use the puppet to request some large 
resource (or few small resources) over the connection 
with S before initiating the sequence exposure attack; the 



response increases C's wnd-size. We increase wnd-size 
until it is approximately 2'^. Once a sequence number 
within wnd is detected, Mallory conducts a binary search 
(over the possible e„„ci sequence numbers) to identify 
the exact beginning of wnd, which is the next server se- 
quence number 

In Section|6]we provide an empirical evaluation of the 
complete sequence exposure technique. 



5 Client Sequence Number Exposure 

In recent Windows client versions (from XP SP2 and on- 
wards) the recipient uses the acknowledgment number, 
that is specified within TCP packets, together with the 
sequence number to verify that a packet is valid. In order 
to inject a packet to the TCP stream, Mallory must spec- 
ify an Ack number that is within C's transmission win- 
dow; i.e., Ack for new data that C had sent. The black 
area in Figure |9]represents the 'acceptable' acknowledg- 
ment numbers (transmission window). In this section we 
show how to take advantage of Ack number validation to 
expose the client's sequence number. 



5.1 The Client-Sequence Test 

Similarly to the test we presented in the previous section, 
we build a three step client-sequence test where the first 
and last steps provide Mallory with the current value of 
C's IP-ID. In the second step Mallory sends a spoofed 
probe, C's response to this probe depends on the Ack 
number Mallory specifies. 

The test is derived from another observation from the 
TCP specification ll36l (Section 3.9, page 72). The rele- 
vant statement refers to an acknowledgment packet that 
carries data and contains a valid sequence number; i.e., 
success in the previous server sequence exposing phase 
is required to initiate this phase. The specification dis- 
tinguishes between two cases regarding the acknowledg- 
ment number in the packet, see illustration in Figure |9] 

Case 1: the packet contains a duplicate Ack (gray area 
in Figure [9]l, or acknowledges data that was sent, but not 
already acknowledged (black area in Figure |9|. In this 
case the recipient is supposed to continue processing the 
packet regularly (see [36.1 ). However, a Windows recip- 
ient (e.g., C) silently discards the packet if it is in the 
gray area (since acknowledgment is invalid); otherwise 
(black area) its data is copied to the received buffer for 
the application. 

Case 2: In the complementary case that the acknowl- 
edgment number is for data that was not yet sent (white 
area in Figure [9]), the recipient discards the segment and 
immediately sends a duplicate Ack that specifies his cur- 
rent sequence number, NXT. 
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Figure 9: Ack Number Map. UNA is the lowest unac- 
knowledged sequence number, NXT is the next sequence 
number that C will send. Acknowledgments for data 
in the gray area are considered duplicates, acknowledg- 
ments for data in the white area are for unsent data, i.e., 
invalid. In the black area are sequence numbers for sent 
un-Acked data. Note that the 32-bit Ack field is cyclic. 



Hence, when C receives an acknowledgment packet 
that specifies an acceptable sequence number, i.e., within 
his flow control window (wnd), then: (1) in case that the 
specified Ack number is after UNA, C sends an acknowl- 
edgment; either since data had arrived (black area), or 
since the packet acknowledges unsent data (white area). 
(2) In case that the Ack number is before UNA (gray 
area), then C (running Windows) discards it. 

The probe which we use in the client sequence test 
specifies the acknowledgment number to be tested {an) 
and has two important properties: (1) the probe packet 
specifies sn, a sequence number that is within C's wnd 
(discovered in the server sequence exposing phase); (2) 
the probe packet specifies data. 
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Figure 10: Client-Sequence Test. The dashed arrow 
marks the duplicate Ack that C sends S in case that an 
is in the white area in Figure |9] If y — / = 1, then C did 
not send that packet; in this case Mallory identifies that 
an is below UNA (i.e., in the gray area in Figure |9]l. 



5.2 Ack Number Binary Search 

The client-sequence test allows Mallory to conduct a bi- 
nary search for the acknowledgment number that the 
chent expects. If the chent-sequence test for the ac- 



knowledgment number an indicates that C did not send 
any packet between the two queries, then an is before 
UNA (in the gray area in Figure|9]l. Otherwise, Mallory 
concludes that an is after UNA (in the black or white area 
in Figure |9]l. 

The gray and white areas in Figure |9] are of equal size, 
and the black area (sent bytes without acknowledgment) 
is usually relatively small. This allows Mallory to per- 
form a binary search for UNA; each time eliminating ap- 
proximately half the possible numbers. The 32-bit length 
of the Ack field (32 bits) implies that there are 32 itera- 
tions. 

6 Sequence Exposure in Practice 

In this section we discuss the applicability of the se- 
quence exposure technique in practice; we assume the 
model presented in Section[T] 

6.1 Implementing Test Queries/Responses 

The server and client sequence tests we described in Sec- 
tions|4]and|5]use packets that Mallory receives from C to 
learn the effect of the (spoofed) probe packet. Mallory 
can persuade C to send her such packets by using the le- 
gitimate TCP connection she has with C: a query is some 
short data packet that Mallory sends to C, the response is 
the C's acknowledgment sent back to Mallory. 

This method allows Mallory to bypass typical firewall 
defenses since all packets in the test appear to belong 
to legitimate connections (requests to C-Mallory connec- 
tion, probe to C-S connection). Specifically, Windows 
Firewall does not filter this technique. 

6.2 Detecting Packet Loss 

In order to succeed in sequence exposing, Mallory must 
identify when test packets are lost since the correspond- 
ing test will yield a wrong result. For instance, if a probe 
is lost, then its test will indicate that C respond to the 
probe and mislead Mallory. 

Mallory detects a lost probe by repeating tests that 
indicate the client did not send a response (i.e., when 
j — / = 1). There should be only few such tests: one when 
probing for the server's sequence number and about six- 
teen during the binary search for the client sequence. 

Mallory detects lost queries and responses by employ- 
ing TCP congestion control. Since we implement the 
queries as data sent on a TCP connection, we are able to 
detect a lost query similarly to TCP congestion control 
mechanism: if Mallory receives several duplicate Acks, 
then she assumes that the corresponding query (a data 
packet) was lost. In this case Mallory repeats all the tests 
that she performed between the corrupt test and until its 
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detection. Ma I lory detects a lost response by identifying 
that no Ack was received for one of the queries (instead 
an accumulative Ack was received); in this case she just 
repeats the invalid test. 

6.3 Test Errors 

The sequence exposure process uses the global IP-ID to 
determine whether a probe caused Cto respond. How- 
ever, since every packet that C sends increments the IP- 
ID, errors may occur. 

Such errors can appear only in tests where C does not 
respond to the probe: if C sends a packet in response to 
the probe, then the IP-ID is incremented, and the differ- 
ence in IP-ID values of the responses that Ma I lory sees is 
at least 2; i.e., in this case Mallory always concludes that 
C had sent a packet]^ 

Hence, there are only few tests where an error is pos- 
sible: during server sequence exposure only one test 
should indicate that no packet was sent, i.e., that Mallory 
found a sequence within the recipient flow control win- 
dow. Mallory then conducts a binary search over the val- 
ues in the flow control window to find the exact sequence 
number. There are approximately 16 iterations to this bi- 
nary search, on average, half of these indicate that C does 
not send a packet in response to the probe. Similarly, the 
binary search for the client-sequence includes 32 itera- 
tions, on average 16 tests should indicate the C did not 
send a packet. 



6.4 Experiments 

In this set of measurements we evaluate the sequence ex- 
posure technique; in Sections [2] and [3] we evaluate the 
full attack (that requires sequence exposing and different 
successful 'meaningful' injections). The server in these 
measurements is runs Apache, and the client is an up 
to date Windows machine (protected by Windows Fire- 
wall). 



Figure 11 illustrates the success probability for dif- 
ferent packets per second averages and when the pup- 
pet runs on different browsers. The average time for a 
successful sequence exposure is 102 seconds (standard 
deviation 18 seconds); this is the estimated time we re- 
quire the client to stay in the attacker's site to conduct 
cross site scripting and initiate denial of service attacks 
(see Sections [2] and (3)1 1^ Attacker and client bandwidths 
are respectively 1 and 10 mbps. 



^We assume that Mallory can send these packets with (small) inter- 
packet delay, such that reordering in the test pack ets is a rare. 

^The web spoofing attack presented in Section[^4]requires that the 
victim will stay in the attacker's site until he accesses the web-page that 
attacker wishes to spoof. 
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Figure 11: TCP sequence exposure success rate. Each 
measurement is the average of 50 runs, error bars mark 
standard deviations. 

In appendix [A] we provide a detailed comparison be- 
tween our sequence exposure technique to the one previ- 
ously presented in lIZTl . 

7 Defense Mechanisms 

The attacks in this paper relay on successful exposure 
of the sequence numbers, the technique we presented 
for this task uses the global counter property of the IP- 
ID implementation in Windows machines. Deployment 
of IPv6 mitigates the IP-ID attack vector since the IPv6 
fragmentation header (that specifies the IP-ID) is only 
present in fragmented packets. In most implementa- 
tions, TCP employs path MTU discovery to avoid IP- 
fragmentation. Hence, TCP connections over IPv6 are 
usually immune to our attacks. 

In this section we propose defenses that prevent off- 
path sequence exposing. Our mechanisms are of two 
types, those deployed at the client-end, and those at the 
server-end. Each mechanism blocks the attack even if 
the other side is unprotected; i.e., servers and clients can 
independently protect themselves. 

7.1 Server-End Defense 

The defense at the server end uses feedback that the 
client machine (that runs the puppet) involuntarily sends 
as a side effect of the ID-exposing process. For every 
wrong guess of the server sequence number, the client 
sends the server a duplicate Ack (see section |4] and Fig- 
ure [8]). We monitor the acknowledgments that the server 
receives to detect the attack. The following two firewall 
rules provide indications of an ongoing sequence expo- 
sure attempt. 

The first rule verifies that in no point in time the server 
receives more Ack packets than the number of un-Acked 
data packets that he had sent to the client. However, the 
adversary can trick this rule by using the puppet to re- 
quest some data from the server, the short window of un- 
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Acked packets ('in transit') allows testing few sequence 
numbers. 

We can further improve detection of the sequence ex- 
posure attack for connections that employ the TCP se- 
lective Ack option. This option is used by most mod- 
ern browsers, including Internet explorer, Firefox and 
Chrome. A selective Ack specifies the sequence numbers 
of out-of-order data that was received by the sender and 
allows to distinguish between a duplicate Ack generated 
by a network loss and a duplicate Ack due to sequence 
exposure attempt. 

The second rule is enabled when the selective Ack op- 
tion is used; it verifies that no two sequential Ack packets 
that the server receives are identical. Normally, a dupli- 
cate Ack is a result of a packet, p, that arrives out-of- 
order. In this typical case, p's sequence number must 
still be in the recipient's flow control window; hence, p's 
data is queued and the recipient sends a duplicate Ack 
to the source. The selective Ack attached to this feed- 
back notifies that p's data was received. However, in the 
case of a sequence exposure attack, most of the probes 
that the attacker sends are out of the recipient's (client's) 
flow control window and are discarded. Therefore, the 
duplicate Ack response to a probe is identical to the pre- 
vious Ack that the server had received. 

After several indications of an attack, the firewall tears 
down the connection. Note that abuse of this mechanism 
to cause the server to close a legitimate connection with 
one of his clients requires the adversary to send to the 
client a probe that specifies the correct connection four 
tuple. However, since in contrast to our attacks, the off- 
path attacker does not create the legitimate connection 
(that she tries to tear down), it is challenging to expose 
the connection parameters (addresses and ports). 

7.2 Client-End Defense 

In this subsection we propose modifying the IPv4 identi- 
fier at the client's firewall (to replace the global counter). 
Since the identifier is only used by the recipient to match 
packet fragments, when a packet arrives at the sender's 
firewall, it can modify the IP-ID field without any im- 
plications on the sender or recipient (even if the packet 
will be fragmented later on the route). When a packet 
arrives in fragments at the firewall, then it must map all 
fragments of the same packet (those that specify the same 
reassembly four tuple - IP addresses, protocol and IP-ID) 
to the same identifier. 

The first, intuitively appealing direction seems to be 
using random identifiers. However in IPv4 this is not 
recommended, according to the birthday paradox, in 
roughly 1 .2^21^ = [l .2 • 2^] = 307 packets there wifl be 
a repetition (since the field is 16 bits long), which would 
cause fragments of one packet to be mis-associated with 



others, and hence cripple performance. 

The IP standards ll35l[TTl specify that IP fragments are 
associated with a packet according to four parameters: 
source and destination addresses, transport layer proto- 
col (e.g., TCP), and identifier Therefore, a simple solu- 
tion would be that each source, destination, protocol tu- 
ple will be associated with a different identifier counter, 
initialized by a keyed pseudo random function /, i.e., the 
initial identifier is fk{source, dest, protocol). In Linux, 
the choice of IP-ID is similar, but is only based on the 
source and destination addresses. 

FreeBSD supports using random IPv4 IDs which are 
permuted locally: a packet is assigned with a random 
IP-ID that was not specified in one of the recent (8192) 
packets that were sent|^ Both Linux and FreeBSD ap- 
proaches immune the TCP connection to our attacks. 



8 Conclusions 

In this work, we show that the folklore belief that TCP 
is secure against spoofing-only, off-path attackers is un- 
founded. We show practical, reaUstic injection attacks. 
We further show that this allows crucial abuses, breaking 
the same-origin policy defense which is critical to web 
security, and allowing devastating DoS attacks. 

One important conclusion is that Bellovin |10l was 
right: TCP was never designed for security, and should 
not be expected to provide it. To ensure authentica- 
tion and confidentiality, even against (only) spoofers, we 
should use secure protocols such as SSL/TLS |12| or 
IPsec ||231 . SSL/TLS may not suffice to prevent (lower- 
layer) attacks such as the DoS attacks presented in this 
paper (Section [3]i; to prevent these too, we should use 
lower-layer security mechanisms, preferably IPsec or 
other mechanisms, e.g., see ll42l[T6l . 

A potentially more controversial conclusion is that ba- 
sic vulnerabilities should be investigated and fixed, even 
before demonstration of a complete, practical, exploit. In 
this paper, we went into great length to prove the practi- 
cality of the vulnerability, since earlier results were con- 
sidered as 'impractical'. We believe that the network 
security community should adopt a more prudent ap- 
proach, publishing and addressing issues and potential 
vulnerabilities, without waiting for a complete exploit. 
Compare the approach in the cryptographic community, 
where even yet-theoretical attacks are taken into account, 
published and motivate design of improved ciphers. 



The default FreeBSD configuration uses a globally incrementing 
IP-ID, as in Windows. 
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A Comparing Performance of TCP Injec- 
tion Attacks 

In this appendix we compare the existing approach and 
technique for TCP injection presented in [271 to those 
presented in this paper. The significant difference be- 
tween the two approaches is that ll27l injects data to a 
legitimate existing connection between two peers (C and 
S) where in this paper we use a puppet to create the vic- 
tim connection. This difference has three implications 
we describe below. 

First, the attacker must identify the connection be- 
tween C and S and expose its parameters (IP addresses 
and ports). In fZTl attacker is assumed to have previous 
knowledge of the client and server addresses as well as 
the server's port; in this paper we assume only knowl- 
edge of the server's address and port which are usually 
available. In order to expose the client's port, in |27] 
the attacker performs a variant of the idle scan, indirectly 
scanning all possible client ports. The scan is as follows: 
the attacker sends a SYN to the server spoofed as if from 
the client; if there is already a connection through the 
client port specified in the SYN packet, then the server 
ignores the spoofed SYN. Otherwise the server sends a 
SYN/ACK packet to the client who will respond in RST. 
The attacker uses the global IP-ID to test whether the 
client sent a packet in response. 

Implementing this method for probing the client port 
has a few challenges: (a) this technique is filtered by typi- 
cal client firewalls (e.g., Windows Firewall) that will dis- 
card the SYN/ACK server response in case that the client 
did not first send a SYN. (b) attacker must run a synchro- 
nized attack, querying for the client IP-ID, then assume 
that the server probe had arrived and query for the IP- 
ID again; if during this time C sends a packet or server 
SYN/ACK does not yet arrive then the test is invalid. 

In contrast, we create the connection using the puppet 
and identify the client port by using an insight on Win- 
dows port allocation paradigm. This allows us to form 
a connection with an 'interesting' server and efficiently 



detect its parameters (see Section 2.1 



Second, the attacker in lt27J must cope ongoing traffic 
over the victim cormection itself. Such traffic fails the bi- 
nary search for the client sequence number (see Section 
|5]l since this phase requires specifying a valid sequence 
number (which keeps changing due to traffic on the con- 
nection). Moreover, |27| does not describe how to im- 
plement the queries to ( 1 ) avoid firewall filtering and (2) 
detect network losses. In the approach presented in this 
paper, the attacker controls the connection since her pup- 
pet makes the requests for the server Hence she is able 
to avoid traffic on the connection while exposing the se- 
quence numbers. The legitimate TCP connection with 
the client is used to implement the queries (see details in 



Section|6]). 

In Figure [12] we compare the success rates of our at- 
tack to that described in |27 1 where the victim connection 
in while running the attack in 12711 has only a modest 10 
kbps traffic rate (since attacker does not control the traffic 
rate in this case). The comparison is for different network 
delays between the client and attacker; the longer the de- 
lay, the more time until the attacker receives feedback 
and the more traffic that passes on the connection. Since 
1271 does not specify how to implement the queries, we 
used our method, i.e., on a TCP connection between the 
client and the attacker. We assume that the attacker in 
l27l successfully detects the client port (despite the chal- 
lenges above). We also assume that the client sends an 
average of 32 packets per second to other peers. 
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Figure 12: Comparison of sequence exposure tech- 
niques. Each measurement is the average of 50 runs, 
error bars mark standard deviations. 



The third difference between our approach to 1271 re- 
gards to the practical challenge of performing a 'mean- 
ingful' injection. That is, after a successful exposure of 
sequence numbers, the attacker should identify the right 
time to inject his data; For example, to perform the XSS 
attack, the spoofed response must arrive after the client 
had sent a request; it is hard for an off-path attacker to 
detect that time. In contrast, the attacks in this initiate 
the request using the puppet and inject the response (see 
Section|2]|. 
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